1. Technical Field
The present invention relates to security or financial transactions and, more particularly, to a system and method for allowing a security syndicate issuer to monitor syndicate transactions during the order and sale of the security syndicates.
2. Description of the Related Art
There are various types of security syndicate offerings conducted in the securities market. One type of security syndicate offering, for example, involves the sale of municipal bonds. During a security syndicate offering of municipal bonds, various transactions are conducted to solicit bids for, and facilitate the sale of the municipal bonds. These transactions can be very complex and time consuming because the security syndicate offering can be valued at, for example, over one (1) billion dollars. Furthermore, processing the security syndicate offering requires interaction between a large number of participants. In general, the participants form a syndicate group consisting of financial institutions, underwriters, etc. The syndicate group pool their resources to share the underwriting liability for a given security syndicate offering by a security issuer.
A security syndicate offering can include, for example, four general transaction periods, namely communication, pricing, order, and allotment. During the communication period, information regarding the details of the security syndicate offering, for example, is communicated to all members of the syndicate. Once the information has been received, the syndicate members make a commitment to purchase a portion of the transaction value. The pricing period represents, for example, the time it takes to negotiate or otherwise arrive at the terms for purchasing the security syndicates. For example, the terms can include the interest rates, maturities, etc. The order period begins after the pricing. During the order period, the syndicate members use their sales forces to contact financial institutions, asset managers, individual investors, etc. to solicit orders for the sale of the security syndicates. Finally, there is the allotment period, wherein a syndicate manager makes a decision as to which orders will actually be filled. This is necessary because there are times when the syndicate members receive more orders than the value of the security syndicate offering.
Transactions conducted during the security syndicate offering can have various degrees of importance to both syndicate and non-syndicate members. One such party (or member) is the security syndicate issuer. The issuer is the person, entity, municipality, etc. offering the security syndicates for sale. The issuer is particularly interested in the order period. The order period can provide an indication of how the security syndicates are selling. This will, in turn, allow the issuer to know if the security syndicates were appropriately priced and whether the syndicate members will be able to complete the sale of the security syndicate offering.
Traditionally, the issuer would periodically contact a lead syndicate member (e.g., a senior manager) and request an update on the number of bonds that have been sold. Availability of a senior manager depends on the type of security syndicate offering. In a negotiated bond offering, for example, there is only one senior manager responsible for overseeing the entire deal. In a competitive bond offering, multiple senior managers can share responsibility for overseeing the deal.
The frequency with which the issuer contacts the senior manager depends, in part, on the particular issuer. For example, one issuer may contact the senior manager two or three times throughout the day, while another issuer may contact the senior manager every hour or even more frequently. Another factor affecting the issuer is the speed at which the bonds are being sold. For example, the same issuer may contact a senior manager more frequently if the bonds do not appear to be selling quickly. In competitive deals, the issuer may contact multiple, or all, senior managers to determine status information on the deal.
The process of contacting a senior manager (or multiple senior managers) can be very time-consuming and tedious. For example, the senior manager must be prepared to provide updated information regarding sale of the bonds. Since the information may be changing dynamically, the senior manager must also devote time to tabulating the information. Consequently, resources will not be available to market and solicit the sale of bonds.
Various electronic systems currently exist for trading bonds and managing transactions associated with bond trading. For example, U.S. Pat. No. 5,915,209 to Lawrence, incorporated herein by reference, discloses a computer-implemented bond trading system. The system attempts to facilitate a private auction of bid wanteds between a central brokers' broker and multiple prospective bidders and to maintain a reference database of accurate bond lot descriptions.
FIG. 23 is a reproduction of a preferred embodiment of the system disclosed in the '209 patent (originally labeled FIG. 1). Referring to FIG. 23, a software-enabled, computer-implemented municipal bond trading system 310 is provided for use by SEC-registered municipal bond brokers firms to serve the community of SEC-registered securities brokerage firms who deal with the public, such as selling traders 314 and buying traders 312, for executing transactions in unlisted securities, especially municipal bonds, without disclosing the seller to the prospective buyer. The municipal bond trading system 310 enables a broker who deploys it to perform a centralized market-making function in a manner providing many of the advantages of a live exchange such as the New York Stock Exchange, without, in preferred embodiments, requiring an exchange license. Although the municipal bond trading system 310 is shown in FIG. 23 as occupying a central function between sellers such as selling trader 314 and buying traders 312, the municipal bond trading system 310 can include components running at the premises of buying traders 312 and at the premises of selling traders 314 to integrate both sellers and prospective buyers into a coherent market-making system.
A job lot 316 comprises a list of one or more bond lots, each of which is a bid wanted, offering or a dollar bond quote. “For sale” is an industry phrase which means that a seller has accepted a bid at a level reasonably close to the lot's value and will execute on the bid. A selling trader 314, who may be an owning institution or individual but is preferably an SEC-registered securities broker dealer, transmits one or more job lots 316 of bonds for sale to the municipal bond trading system 310 maintained by a broker, who functions as a “market-maker,” at any time convenient to the selling trader 314. Transmission of job lots 316 to the municipal bond trading system 310 can be accomplished in any conventional manner: written, faxed, telephoned, or electronically effected in a file that can be directly processed by the municipal bond trading system 310 via confidential e-mail, as are communications from the market-maker to the seller, over data lines 315. The seller can be computer-linked to the municipal bond trading system 310 on a LAN or a WAN.
After appropriate central processing employing the municipal bond trading system 310, bid wanteds are circulated to buying traders 312 in order to solicit bids 318. Bids 318 are received from one or more buying traders 312 and transmitted to the seller by any suitable means, such as fax or computer network, as described above, for further processing. If the selling trader 314 accepts the bid 318, the brokers' broker marks the lot “for sale” and completes the execution, preferably with the assistance of the municipal bond trading system 310, and then transmits customary buy and sell tickets 322 to the selling trader 314 for their internal processing. If traders are utilizing the system on their workstations, they will execute a “buy” utilizing the program while the broker executes a “sell.”
The system can be operated as an exchange, providing a direct transaction between a selling trader 314 and a bidding trader 312, conducted through the intermediary of the trading system 310. The double step required in conducting a buy-sell transaction with both the selling trader 314 and the buying trader 312, can be eliminated. The trading system 310 may also receive bid wanteds in electronic form, without vocal communication, and system-select the best bid for entry and referral to the selling trader 314 for acceptance, which electronic non-vocal automated trading procedure currently requires an exchange license. The system can be tailored to transmit information of the transaction to the trader's in-house processing system for proper record-keeping and accounting and to maintain an inventory of bond lots in position for the trader.
The municipal bond trading system 310 herein facilitates fulfillment of this requirement by enabling rapid distribution of job lots 316 to a wide base of customers, selling traders 312, and by providing quick and efficient means for evaluating, collating and transmitting even a large number of bids 318 to the seller for further action. Before a trade is executed, a municipal bond lot must be identified with a Central Unified Security Identification Process number, herein referred to as “CUSIP (trademark)” issue identification number. CUSIP is a registered trademark of the American Bankers Association (“ABA”). The bond lot must also have an authentic description and a par value, usually some thousands of dollars, describing the size of the lot. Unlisted bond descriptions are subject to change at any time. For example, bond ratings are continually changed by rating agencies, and a bond may be called in for repayment on as little as thirty days' notice. Ratings and calls are an essential part of the description of a security and can dramatically affect the character of the investment. It is accordingly highly desirable to include such changes of description in each bid wanted before distributing it, which presents a problem.
To provide contemporaneous descriptions rapidly, in a manner suitable for processing lots in volume, a security master database 324 is provided, wherein bond descriptions are stored cumulatively, whenever the municipal bond trading system 310 encounters them, to be available for future use. The security master database 324 can be primed or supplemented with preferred lists of bond descriptions and has no particular limits, but it is much smaller than the reference database 322, thus enabling a faster search and access capability. For municipal bond trading, the reference database 322 is preferably the KIS database.
Once prepared, the bid wanted form 326 is distributed to the buying traders 312 to enable them to bid in a timely manner. Bids are first solicited, and if necessary, collected centrally, and then evaluated to determine the high bidder. Following this process, a compilation of bids is transmitted to the selling trader 314 for action. These steps are accomplished in a silent auction, conducted electronically or on paper without the necessity of voiced person-to-person communication modes, such as telephone calls. In this silent auction, each bid wanted is provided with a bidding deadline and is broadcast to reach multiple buying traders 312 prior to that bidding deadline. Traders 312 wishing to bid on the lot offered are required to return a completed bid wanted form 328 to the central municipal bond trading system 310 prior to the deadline if the bid is to be considered. Bidding closes when the deadline passes. After acceptance of a high bid by the selling trader 314 and the completion of any closing formalities, a bought-from ticket 334 is system-prepared and transmitted to the buyer for their records and processing, preferably electronically.
Bidding traders 312 are linked to the municipal bond trading system 310 over a computer network so that bidding deadline alerts can be overlaid, or otherwise displayed on a buying trader's screen at various times throughout the auction process to advise of the approaching commencement of an auction on a particular lot, to warn of expiration of the time limit, and to provide interim advisories as the auction proceeds. Such alerts are preferably displayed on a system-wide basis on all selected and operational networked screens including those of brokers working with other applications on-screen at the time. If desired, bidding trader modules of the municipal bond trading system 310 software can include switches or filters permitting the user to choose which alerts should be flashed on-screen or which should be allowed to interrupt other applications.
An on-screen bidding advisory message requires action by the bidding trader 312 to remove it, such as pressing a particular key, and the advisory may include options, for example, “Display bid wanted form?”, if the form is not already on-screen. The system utilizes fax transmissions of bid wanted forms 326 to a specified group of buying traders 312 who can receive the bid wanted form 326 on paper, by computer or in both ways. This method of transmission is also suitable for distributing bid wanted forms 326 to any individual buying trader 312. In preparing job lots 316 for fax broadcasting, the municipal bond trading system 310 organizes all active job lots 316 in a queue so that the broker can designate, or “tag,” selected lots for faxing. The system sorts tagged lots for faxing by auction time, and sends them to a fax service 330 at a predetermined interval before the auction commences.
The bid wanted form 326 contains the full particulars of each bid wanted lot, including its CUSIP (trademark) number and description, state of origin, maturity, par amount, and coupon values (yield and concession particulars, net yields, and dollar, gross and net dollar price) if appropriate. For use in a fax-broadcast marketing system, the form preferably also includes blanks completable by a bidding trader with bid particulars, yield, dollar or other amount, as appropriate, and bidder identifiers, including the name of the bidding trader. Yields and other calculable values can of course be system-calculated and automatically posted from base data. A buying trader 312 can quickly write minimal bid information on a hard copy of such a bid wanted form 326, sign it, and fax it back to the market-maker, who receives a signed bid with full and accurate lot particulars complying with regulatory requirements and which does not need to be checked, verified or completed.
U.S. Pat. No. 5,809,483 issued to Broka et al., incorporated herein by reference, discloses an on-line transaction processing system for bond trading. The system allows for monitoring of information regarding debt securities and reporting trades in the debt securities market. FIG. 24 is a reproduction of a preferred embodiment of fixed income pricing system (FIPS) as disclosed in the '483 patent (originally labeled FIG. 1).
As shown in FIG. 24, the FIPS processing system 400 includes business functions layer 410, infrastructure layer 420, and platforms layer 460. Business functions layer 410 provides the basic services accessed by users and includes the following services: Trade Reports 411, Market Services Control 412, Quotes 413, Issues 414, News 415, Participants & Users 416, and Statistics 417.
Infrastructure layer 420 includes the communication mechanisms and other tools that allow the various FIPS processes to work together. Infrastructure layer 420 includes workstation services module 421, network services module 430, and host services module 440. Workstation services module 421 includes those services required to use a workstation and include: User Interface Management 422, Information Model 423, Host Connection 424, Broadcast Receiver 425, Message Handling 426, Logging 427, and Utilities 428.
Network services module 430 includes those services which provide access to the entire network. These include: Routing 431, Message Transfer 432, and Filtering 433. Host services module 440 includes those services provided for the FIPS host and include: Security 441, Beginning-of-Day & End-of-Day 442, Message Handling 443, Communication 444, Broadcast 445, Timer 446, Logging 447, Message Naming 448, bond quotation dissemination system (BDQS) 449, computer-to-computer interface (CTCI) 450, and Standard & Poor's (S&P) Data Loading 451.
During most system interactions, one of the services in infrastructure layer 420 will interact with one of the functions in business functions layer 410. For example, the Security service 441 works with the Participant & User business function 416 to authorize and authenticate users when they log on. Different services in infrastructure layer 420 may also communicate with each other. For example, the Broadcast service 445 works with the Communication service 444 to send messages to multiple platforms including PC/Windows 461 and Sun/Unix 462. Business functions can have relationships with each other as well. For example, FIPS system administrators may use Market Service Control 412 with the Trade Reports 411 to restrict a user's ability to generate trade reports.
The previously described systems appear beneficial for addressing specific problems in the financial market. For example, the '483 patent addresses problems associated with monitoring debt security information and reporting trades in the debt securities market. However, existing systems, while capable of addressing some problems, simply do not address the problems we have discovered associated with security syndicate offerings such as, for example, allowing an issuer to view the progress of sales of security syndicates or access information conventionally available only from a senior manager.
Accordingly, we have determined that there exists a need for a system that reduces the difficulties encountered by issuers during security syndicate offerings.
We have also determined that there exists a need for a system capable of allowing an issuer to independently monitor the status of security syndicate sales.
We have also determined that there exists a further need for a system which does not impose on a senior manager's duties during a security syndicate offering.
We have also determined that there exists a still further need for a system capable of monitoring transactions during a security syndicate offering.